Filter condition that includes string lookups as an optional alternative to filtering directly on IDs
Nullable
ReportingStringLookups :
object
Can be specified and will be used as an alternative to
ReportingStringsDependentLists : bool
Normally each property in ReportingStringsLookups is independent from eachother, eg: given the following example ReportingStringsLookup setup:
OutletName: ['o1', 'o2', 'o3']
Terminal: ['t1', 't2']
any aggregate with EITHER o1/o2/o3 for outletname and t1/t2 for terminal will pass. Essentially the condition will read "WHERE OutletName in (o1, o2, o3) AND Terminal in (t1, t2)"
However by setting this property to true you will be asserting that every filter condition with a List of values will have a 1-1 correspondence with eachother therefore the above
example becomes a condition like "WHERE ((OutletName = 'o1' AND Terminal = 't1') || (OutletName = 'o2' AND Terminal = 't2') || (OutletName = 'o3'))
Caveats - setting this will ONLY compare ListCondition elements inside ReportingStringLookups - any Value/Range/Other elements will be ignored
NegateCondition : bool
boolean inverts conditions used by this instance
Nullable
FilterID :
number (int)
The unique (per query) ID for this filter. Will be set automatically by the server, no need to set it. Duplicating this value will
likely result in query failures
Example
{
"ReportingStringLookups": {},
"ReportingStringsDependentLists": true,
"NegateCondition": true,
"FilterID": 321
}